Hi @the-thing , thanks for this, looks very useful. I also recalled that issue #357 when reading your description.
Does it make sense to have some kind of scheduled github action for the stress test?

I'm not sure about the CI integration.

The issues I can see are

• these stress tests take a long time to run
• there is no standard way to capture the results (at least I'm not aware of), but the reports in are generated in the console and html files
• the action would have to wait for main pipeline to finish and download jcstress module files and run them (I think this is relatively easy to do)

I don't think I have seen jcstress running as part of CI pipeline before. Normally when one suspects a concurrency bug. You write jcstress test, fix it and rerun. Having it as part of the project makes things easier with manual re-runs and setup.

However, I have seen benchmarks being run automatically for continuous performance monitoring.

It depends how you are planning on using it. I imagine there is another job that runs after the main CI build that always succeeds and if anyone is interested can view the results on demand. Is that what you are after?

The main interest for me (besides finding existing bugs) was that no further bugs are introduced. Just wanted to automate it because otherwise I'll probably forget to run it on a regular basis. =)

This is doable, but it might require additional effort. You would also have to expect that the current action's build times to increase significantly.

You will have to write tests first. I would expect that whoever opens a new PR with concurrency fix will back it up with jcstress test and mention to run it.